Service registry policy aggregator

ABSTRACT

A service registry and repository based on a triplestore comprises: receiving a request to aggregate a service document; shredding elements of the service document to create logical objects within the triplestore; for each logical object, searching for all policy attachments logical objects that have a relationship with the logical object; for each located policy attachment, retrieving details of the policy and building a list of policies and associated logical objects in the repository; and returning an indication of the list of polices and associated logical objects. The list of logical objects and associated polices is used to compile a service document containing details of policies that have relationships with the selected service document logical objects. Objects that have associated polices are rendered with a hypertext policy icon next to the object and selection of the hypertext policy icon opens a new window with the policy details.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application claims priority to GB 09167242.8, filed on Aug.5, 2009, the disclosure of which is incorporated herein by reference inits entirety.

BACKGROUND

Various aspects of the present invention relate in general, to registryand repository systems and methods, and in particular, to serviceregistry and repository systems and methods based on a triplestoredatabase for operating a policy aggregator.

Service oriented architecture (SOA) is a business-driven, informationtechnology (IT) architectural approach that supports integratingbusiness domains as linked, repeatable business tasks, or services. Thebasic building block is a service document that defines an associatedservice so that the service can be managed with other services. Aservice document contains information about an associated service,including the location of the service, details about the service and howto access the service. Service documents are used by analysts,architects, and developers during a Development Phase of the SOA lifecycle to locate services to reuse and to evaluate the impact of changesto service configurations. Service documents are variously described asmetadata, objects, descriptions, entities and artifacts.

A service repository stores the service document and allows access tothe service document and thereby the corresponding service. A serviceregistry is an index of a subset of information about a service (forexample the location and name of service document) enabling thecorresponding service document to be located and accessed in arepository (or even the corresponding service located at the serviceprovider). An integrated service registry and repository allows aservice operation to use both the indexed service information in theregistry and the detailed service information in the repository. Anexample of an integrated service registry and repository is the IBM®WebSphere® Registry and Repository (WSRR).

Such an integrated service registry and repository has advantages ofgreater business agility and resilience through reuse compared toseparate service registry and repository systems. Further advantages oflooser coupling, greater flexibility, better interoperability, andbetter governance also arise from the integration of a service registryand a repository. These advantages are addressed by separating servicedescriptions from their implementations, and using the servicedescriptions across the life cycle of the service. Standards-basedservice metadata artifacts, such as Web Service Definition Language(WSDL), extensible mark-up language (XML) schema, policy or ServiceComponent Architecture (SCA) documents, capture the technical details ofwhat a service can do, how it can be invoked, or what it expects otherservices to do. Semantic annotations and other metadata can beassociated with these artifacts to offer insight to potential users ofthe service on how and when it can be used, and what purposes it serves.

WS-Policy is a World Wide Web Consortium (W3C) standard that is intendedto provide a means for specifying policies that need to be applied toWeb Services and specifically, service documents. The WS-Policy-Attachspecification, also controlled by the W3C, specifies a standardizedmeans by which policy attachments can be defined to link a policy to aservice object referenced in a service document. Service objects orlogical objects are derived from documents such as Web ServiceDefinition Language (WSDL) documents, Extensible Markup Language (XML)documents, XML schema definition (XSD) documents, Web Service Policy(WS-Policy) documents etc., when they are loaded into the ServiceRegistry environment. The WS-Policy-Attach specification declaresdifferent means of associating policies with target elements in WSDLdocuments: 1) an element in a WSDL document having an embedded policy;2) an element in a WSDL document having an embedded policy referencereferencing an external policy in a policy attachment file; 3) anembedded policy in external policy attachment file having a reference toan element in a WSDL document; 4) and embedded policy reference in anexternal policy attachment file referencing an element in a WSDLdocument and a policy in another external policy attachment file.

A policy is a rule that is applied to an object by an environment. Forinstance, access to an object can be controlled by applying a rule thatthat only entities with a certain token can have access to the object.Since there is more than one way of specifying polices, there is no wayof being able to retrieve a WSDL service definition file thatencapsulates all of the policies that may have been linked directly orindirectly, to or from the logical object referenced in the servicedocument.

BRIEF SUMMARY

According to various aspects of the present invention, a serviceregistry and repository system, computer program product and method ofoperation, comprises receiving a request to aggregate a service documentcomprising elements and shredding the elements of the service documentto create logical objects within the triplestore. Operating the serviceregistry and repository further comprises searching, for each logicalobject, for all policy attachments that have an association with thelogical object, retrieving, for each located policy attachment, detailsof the policy and building a list of policies and associated logicalobjects in the triplestore, and returning an indication of the list ofpolices and associated logical objects.

Further aspects of the present invention may comprise using the list oflogical objects and associated polices to compile a service documentcontaining details of all the policies that have relationships with theselected service document logical objects.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a schematic of service document phases in a service registryand repository according to aspects of the present invention;

FIG. 2 is a schematic of select components of a service registry policyaggregator architecture according to aspects of the present invention;

FIG. 3 is a schematic of an exemplary information architecturearrangement according to various aspects of the present invention;

FIG. 4 is a schematic of an exemplary policy aggregator according tovarious aspects of the present invention;

FIG. 5 is a schematic of a process implemented, e.g., by the policyaggregator of FIG. 4, according to various aspects of the presentinvention;

FIG. 6 shows an example WebSphere Service Registry and Repositoryscreenshot;

FIG. 7 is an exemplary service document before policy informationaggregation; and

FIG. 8 is a block diagram of a computer system having a computerreadable storage medium for implementing one or more of the methodsand/or components described in greater detail herein, according tovarious aspects of the present invention.

DETAILED DESCRIPTION

Various aspects of the present invention provide a service registry andrepository for service documents, e.g., based on IBM WebSphere ServiceRegistry and Repository. Such service documents include traditionalinternet services that use a range of protocols and are implementedaccording to a variety of programming models.

Various aspects of the present invention provide a unified view of WSDLservice definitions that includes an aggregated view of all of thepolicy attachments that have been declared as applicable to elementswithin the WSDL in a service registry environment.

Further aspects of the present invention use a triplestore database tostore data in data structure comprising three pieces of information inthe form subject-predicate-object. The purpose of triplestore is toincrease performance in searching for information in a large volume ofcomplex data and as such is well suited to the application of a serviceregistry and repository where the number and complexity of the data islarge.

Referring now to the drawings and in particular, to FIG. 1, phases of aservice life cycle are illustrated. The phases of the services stored asdocuments in the service registry and repository comprise: ServiceDevelopment; Change and Release Management; and Runtime Integration andOperation. As the integration point for service metadata, the serviceregistry and repository establishes a central point for finding andmanaging service metadata acquired from a number of sources, includingservice application deployments and other service metadata and endpointregistries and repositories. The service registry and repository iswhere service metadata that is scattered across an enterprise is broughttogether to provide a single, comprehensive description of a service.

For instance, as illustrated, the service registry and repository cancollect service metadata associated with the service developmentlifecycle, including model, build and assemble aspects. The serviceregistry and repository can also collect service metadata associatedwith change and release management including test and deploy aspects.The service registry and repository can also collect service metadataassociated with operational efficiency and resilience includingmanagement aspects. Still further, the service registry and repositorycan collect service metadata associated with service endpoint registriesand repositories including Discover aspects. The service registry andrepository further interacts with runtime integration including mediateand bind aspects. Once this happens, visibility is controlled, versionsare managed, proposed changes are analyzed and communicated, usage ismonitored and other parts of the service architecture can access servicemetadata with the confidence that they have found the copy of record.

Software Architecture

Referring to FIG. 2, an illustrative system comprises an applicationserver 8, such as a WebSphere Application Server, a triplestore database9 and a service registry and repository 10, such as a WebSphere ServiceRegistry and Repository. Top level components of the service registryand repository 10 comprise: a registry 12; repository 15; a governor 20;an administration interface 26; a user interface 28; and a programminginterface 30.

The service registry and repository of an exemplary embodiment is aJava™ 2 Platform Enterprise Edition (J2EE) application that runs on aWebSphere Application Server 8 and uses the triplestore database 9 as abacking store to persist the service metadata. The service registry andrepository takes advantage of the role-based access control so thatrole-based views and access control can be turned on when the serviceregistry and repository is deployed as an enterprise-wide application.

The registry 12 offers both registry function and repository functionfor service metadata. The repository function allows users to store,manage and query service metadata artifacts holding servicedescriptions. The registry 12 not only takes care of the documentscontaining service metadata by reliable persistence of the data, but theregistry 12 also provides a fine-grained representation of the contentof those documents (for example, ports and portTypes in some servicedocuments). The registry function makes provision for decoratingregistered service declarations and elements of the derived contentmodels with user-defined properties, relationships, and classifiers. Theregistry 12 provides a policy editor 14, also referred to as a policyaggregator.

Repository 15 stores all artifacts including service documents 414, suchas domain policy definitions, and policy documents 416.

Classification component 22 allows service descriptions and parts ofservice definitions to be annotated with corporate vocabulary and tocapture the governance state. Service classification systems arecaptured in web ontology language (OWL) documents that are loaded intothe Service Registry and Repository using the administrative interface.Service registry and repository entities can be classified with valuesfrom these classification systems, to allow classification-based queriesto be performed, and to allow access restrictions based onclassification.

Access controller 24 supports a fine-grained access control model thatallows for the definition of which user roles can perform specific typesof actions on corresponding artifacts. Visibility of services can berestricted by business area and user roles can be restricted fromtransitioning services to certain life cycle states. This is in additionto the role-based access control provided by the service registry andrepository.

Administration interface 26 supports the import and export of repositorycontent for exchange with other repositories and provides an API forconfiguration and basic administration. The administration interface 26thus supports interactions with the Classification component 22 and theAccess Controller 24.

User interface 28 comprises a web interface and an Eclipse* plug-ininterface to enable interaction with service registry and repository. Aservlet based web user interface (UI) support is the main way for usersrepresenting different roles to interact with the service registry andrepository. The web interface supports all user roles, offering lookup,browse, retrieve, publish, and annotate capabilities, as well asgovernance activities, such as import/export and impact analysis. Asubset of this user interface is offered as an Eclipse plug-in to meetdeveloper needs and analyst users needs that use Eclipse based-tooling.The Eclipse plug-in is used primarily for lookup, browse, retrieve andpublish capabilities. The Web-based user interface can also be used forperforming service metadata management and governance.

Programming interface 30 uses Java and Service Oriented ArchitectureProtocol (SOAP) APIs to interact programmatically with the registry 12.These APIs provide basic create, retrieve, update and delete (CRUD)operations, governance operations, and a flexible query capability. TheSOAP API is used to communicate content using XML data structures. TheJava API is used to communicate content using service data object (SDO)graphs. Using either the user interface 30 or the programming interface28 documents and concepts managed by WebSphere Service Registry andRepository can be created, retrieved, updated and deleted. However,logical entities in the logical model cannot be modified and can only bechanged by updating a document that contains the logical entity.Concepts can be created, retrieved and deleted.

The service registry and repository of an exemplary embodiment supportstwo application programming interfaces (APIs), including a Java-basedAPI and a SOAP-based API that can be used to interact with the registry12, the repository 15, the governance component 20 and theadministration interface 26, respectively. Both APIs support publishing(creating and updating) service metadata artifacts and metadataassociated with those artifacts, retrieving service metadata artifacts,deleting the service metadata artifacts and the metadata associated withthose artifacts, and querying the content of the registry andrepository. The programming APIs use Service Data Objects (SDO) tocapture the data graphs inherent in the content model, allowing accessto physical documents, logical parts of the physical documents, andconcepts. The SOAP API uses XML documents to similarly represent ServiceData Objects to communicate content structures in both the physical andlogical model.

Client browser 40 displays the policy user interface 42 for editing byuser 44.

Information Architecture

Referring to FIG. 3, the information architecture 300 of an exemplaryembodiment is described. Broadly, information architecture 300 hasentities representing service description entities 302 and servicedescription metadata 304. All artifacts have an assigned URI, a name anda description. Examples of each type of artifact are shown in FIG. 3 butare not necessarily referred to in the description.

Service Description Entities 302 comprises physical documents 306,logical derivations 308 and concepts 310. Physical Documents 306 are XMLdocuments that are known as service metadata artifacts. Logicalderivations 308 are the finer-grained pieces of content that result whensome types of physical document are shredded as they are loaded intoRegistry and Repository. Concepts 310 are generic entities that areusually typed, and represent anything that is not represented by adocument in Registry and Repository. All three types of servicedescription entities can be use in queries, have service annotationsapplied, and have relationships established from and to them.

The most elemental building blocks for the WebSphere Service Registryand Repository are the physical documents 306 such as XSD, WSDL, SCDL orWS-Policy documents. In addition any XML service metadata artifact typeor binary document can be stored in WebSphere Service Registry andRepository and receive the benefits of broader visibility, reuse,management, and governance. The coarse-grained model made up fromregistry objects that represents those documents is referred to as thephysical model. Documents are versionable objects in the WebSphereService Registry and Repository content model, which means that inaddition to a URI, name, and description, they also have a versionproperty.

For some of the physical document types, WebSphere Service Registry andRepository derives logical objects and stores them in logicalderivations 308. For instance, WebSphere Service Registry and Repositorycan “shred” a document upon receipt into a set of logical objects toenable users to explore WebSphere Service Registry and Repositorycontent beyond the boundaries of the files stored. Logical objects arenot versionable. For some physical document types, WebSphere ServiceRegistry and Repository defines predefined properties and detectsrelationships to other physical documents. An XSD document, for example,has a target Namespace property and the relationships with otherimported XSD documents, other redefined XSD documents and other includedXSD documents. When an entry for a certain physical document is createdin WebSphere Service Registry and Repository, it is inspected forrelationships to other artifacts. If not already represented inWebSphere Service Registry and Repository, a related artifact is alsoadded, and in either case the relationship between the artifacts isrecorded.

The set of logical derivations comprises the logical model of WebSphereService Registry and Repository. The logical model has entities such asportType, port, and message related to WSDL files, and complexType orsimpleType related to XSD documents. Elements of the logical model haveproperties and relationships reflecting a subset of theircharacteristics as defined in the underlying document. For example, aWSDLService element has a namespace property and a relationship to theports it contains. In an exemplary implementation, all individualresults of document shredding are aggregated into one logical model thatrepresents not only the content of individual documents, but alsorelationships between content in different documents.

WebSphere Service Registry and Repository stores other types of servicemetadata using the XML Document, a generic document type. Documents oftype XMLDocument are not decomposed into the logical model.

WebSphere Service Registry and Repository uses a concept to representanything that does not have a physical document. Concepts 310 are usedto represent a reference to content in some other metadata repository,such as a portlet in a portlet catalogue or an asset in an assetrepository. It can also be used to group physical artifacts together togovern them as a unit, for example, concepts can be versioned.

In addition to content directly related to entities 302, WebSphereService Registry and Repository supports a number of metadata types thatare used to describe entities 302. These metadata types are referred toas service description metadata 304. WebSphere Service Registry andRepository supports three types of service semantic metadata types:properties 312; relationships 314; and classifications 316. All threetypes describe physical model entities, logical model entities, and/orconcepts. For example, service description metadata can be used toassociate a property “businessValue” with a physical model entityrepresenting a WSDL file. It might also be used to define a newrelationship “makesUseOf” between an entity in the logical modelrepresenting a “portType” and an entity in the physical modelrepresenting an XML document. Furthermore one could create aclassification of “importantThings” and associate it with a “port”entity in the logical model and with an entity in the physical modelrepresenting a “Policy” document. This enables semantic queries totarget individual elements of the service metadata, and meaningfuldependency analyses to take place prior to making changes.

Properties 312 are simple name/value pairs that are associated with anyof the Service Description Entities 302. Some properties are assigned bythe system, such as the unique id, the owner, and the last time theservice entity was changed. These system-assigned properties cannot bechanged. Others are derived through the “shredding” of a key-typeservice description document into its logical model. Properties of thistype include name and namespace. Sometimes these system-assigned valuesare allowed to be changed and properties can be created. Such auser-defined property can be used as a simple, unstructured and untypedextension mechanism. Properties 312 can be used in queries, and can beused to establish fine-grained access control.

Relationships 314 tie together one source service description entity toone or more target service description entities. Every relationship isgiven a name and a source is only allowed to have a single relationshipwith a given name. Some relationships are assigned by WebSphere ServiceRegistry and Repository during the “shredding” of key types ofdocuments. The relationship established between XSD documents based onthe importing of one into the other is one such system-assignedrelationship. Relationships can also be user defined. For example, auser can: relate a concept that represents an external object to aservice using a user defined relationship; relate all of the servicedescription documents that will be governed as a unit to a governableentity, and/or relate a monitoring policy to a service endpoint.

A user can load classification 316 into a registry where it can then beused to apply semantic meaning to service description entities 302.Classification systems are documents encoded using the Web OntologyLanguage (OWL). The registry represents OWL Classes as classifiers andinterprets the subTypeOf relationship between those Classes asestablishing a classifier hierarchy. Other OWL concepts such as data orrelationship representing properties or other built-in OWL relationshipsare ignored. A classification system is imported into the registry as awhole and updates are made by importing a modified version of theontology. Any class in the underlying ontology can be used as aclassification, the same classification can be used to classify multipleentities and an entity can be associated with multiple classifications.

Policy Aggregator

Referring to FIG. 4, an exemplary policy aggregator 14 is illustratedcomprising: a service document receiver 402; an object list builder 404;a policy searcher 406; a policy list builder 408; an aggregated documentbuilder 410; and an aggregated document sender 412.

Service document receiver 402 is for receiving a selected servicedocument from a user. In an exemplary embodiment, a universal resourceidentifier (URI) is used to identify the selected document in therepository 15 inside an internet message requesting the policyaggregator to aggregate policies for the selected service document.

Object list builder 404 is for parsing the selected service document forall objects embedded in the selected document or in documents referencedby the selected document (single reference or multiple references). Anillustrative way of building the object list is to shred the elements ofthe service document to create logical objects within the triplestore 9.

Policy searcher 406 is for searching for policies in the selecteddocument or somewhere in the repository. Each policy in the repositoryis parsed for an association to or from objects in the object list.

Policy list builder 408 is for building a list of all the policies thathave associations with objects in the object list, together with theobject, the location of the object and the type of association.

Aggregated document builder 410 is for building an aggregated documentlist of all the associated policies. In an exemplary embodiment, all thepolicy details are included in the document in a discrete way so thatthe user can examine what policies are related to the document. Inanother exemplary embodiment, only references to the policies areincluded.

Aggregated document sender 412 returns the aggregated document to theuser.

Policy Aggregation

Referring to FIG. 5, a method flow 500 of policy aggregator 14 is shownaccording to an exemplary embodiment of the invention.

At 502, the user requests an aggregated service document. The user canrequest the aggregated view in a variety of ways. For example, the usercan request the aggregated view through a user-interface which may, forexample, present a view of the document such as is shown in the screencapture of FIG. 6, which shows that the ‘PortType’ within the WSDLdocument called ‘StockQuote’ has a policy called ‘myTestPolicy’ attachedto it.

At 504, the policy aggregator 14 retrieves all logical objects from therepository representing the contents of the service document. Upon load,the system analyses the documents (which are all XML based) usingstandard parsing techniques in order to derive a set of objects thatrepresent the contents of the documents. These objects are then linkedtogether in the database in order to preserve the structure of thedocument contents and can be retrieved as ‘object graphs’. Object graphscan be considered as a set of software objects that are linked togethervia references in memory to represent a structure of something—in thiscase, the contents of the documents.

At 506, for each logical object, the policy aggregator 14 searches forall policy attachments associated with logical objects that have arelationship with the logical object. In an exemplary embodiment bydefault the search is performed over the whole repository. Therepository can indicate another repository to be searched.

At 508, for each policy attachment, the policy aggregator 14 retrievesdetails of the policy and builds a list of logical objects andassociated policies in the repository.

At 510, the policy aggregator 14 uses the list of logical objects andassociated polices and compiles an aggregated service documentcontaining details of all the policies that have relationships with theservice document logical objects. In an exemplary embodiment the policydetails are included in the document associated with the object in thedocument.

At 512, the policy aggregator 14 returns an aggregated service documentto user and the user client browser renders the aggregated servicedocument.

In an exemplary embodiment, objects that have associated polices arerendered differently from objects that have no associated policies andoptionally, a hypertext policy icon is displayed next to the object.Moreover, the user may be able to examine the aggregated servicedocument, e.g., as rendered in the browser. When the user selects ahypertext policy icon then a new browser window, tab window or pop upwindow is displayed with the policy details. The user can select one orthe window types or configure the Service Registry to default one ofthem.

Example

Referring to FIG. 6, a screen shot illustrates a service document (Name:stockquote.wdsl version:99 URI:1fefb81f-90a2-42e5.81b5.dfbcf4dfb564)containing service elements. This screen capture was taken from IBMWebSphere Service Registry and Repository v6.2 and is essentially an XMLformat. Element PortType Name:StockQuote (a port having a nameStockQuote) has an attachment identified as a policy but no otherdetails. After policy aggregation the aggregated policy details (or areference to the policy) are embedded into the element.

The service document XML code is shown in the left hand of the table ofFIG. 7. The aggregated policy details are show in the right hand columnof FIG. 7 and the arrows in FIG. 7 indicate where in the servicedocument the policy details are inserted.

Other Embodiments

It will be clear to one of ordinary skill in the art that all or part ofthe methods described herein may suitably and usefully be embodied in alogic apparatus, or a plurality of logic apparatus, comprising logicelements arranged to perform the steps of the method and that such logicelements may comprise hardware components, firmware components or acombination thereof.

It will be equally clear to one of skill in the art that all or part ofa logic arrangement according to exemplary embodiments of the presentinvention may suitably be embodied in a logic apparatus comprising logicelements to perform the steps of the method, and that such logicelements may comprise components such as logic gates in, for example aprogrammable logic array or application-specific integrated circuit.Such a logic arrangement may further be embodied in enabling elementsfor temporarily or permanently establishing logic structures in such anarray or circuit using, for example, a virtual hardware descriptorlanguage, which may be stored and transmitted using fixed ortransmittable carrier media.

The present invention may further suitably be embodied as a computerprogram product for use with a computer system. The series of computerreadable instructions embodies all or part of the functionalitypreviously described herein. It is contemplated that such a computerprogram product may be distributed as a removable medium withaccompanying printed or electronic documentation, for example,shrink-wrapped software, pre-loaded with a computer system, for example,on a system ROM or fixed disk, or distributed from a server orelectronic bulletin board over a network, for example, the Internet orWorld Wide Web.

In an alternative, exemplary embodiment of the present invention may berealized in the form of a computer implemented method of deploying aservice comprising steps of deploying computer program code operable to,when deployed into a computer infrastructure and executed thereon, causethe computer system to perform all the steps of the method.

In a further alternative, exemplary embodiment of the present inventionmay be realized in the form of a data carrier having functional datathereon, said functional data comprising functional computer datastructures to, when loaded into a computer system and operated uponthereby, enable said computer system to perform all the steps of themethod.

Referring to FIG. 8, a block diagram of a data processing system isdepicted in accordance with various aspects of the present invention.Data processing system 800, such as a server, may comprise a symmetricmultiprocessor (SMP) system or other configuration including a pluralityof processors 802 connected to system bus 804. Alternatively, a singleprocessor 802 may be employed. Also connected to system bus 804 ismemory controller/cache 806, which provides an interface to local memory808. An I/O bus bridge 810 is connected to the system bus 804 andprovides an interface to an I/O bus 812. The I/O bus may be utilized tosupport one or more buses and corresponding devices 814, such as busbridges, input output devices (I/O devices), storage, network adapters,etc. Network adapters may also be coupled to the system to enable thedata processing system to become coupled to other data processingsystems or remote printers or storage devices through interveningprivate or public networks.

Also connected to the I/O bus may be devices such as a graphics adapter816, storage 818 and a computer usable storage medium 820 havingcomputer usable program code embodied thereon. The processor(s) 802execute(s) computer usable program code to implement any aspect of thepresent invention, for example, to implement any aspect of any of themethods and/or system components illustrated in FIGS. 1-7. Moreover, thecomputer usable program code may be utilized to implement any otherprocesses that are used to implement service registry and repositorysystems and methods, e.g., based on a triplestore database for operatinga policy aggregator, as described more fully herein.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablestorage medium(s) having computer readable program code embodiedthereon, e.g., providing program code for use by or in connection with acomputer or any instruction execution system.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

ABBREVIATIONS

J2EE Java™ 2 Platform Enterprise Edition

SCA Service Component Architecture

SOA Service oriented architecture.

WSDL Web Service Definition Language

WSRR IBM WebSphere Registry and Repository

XML extensible mark-up language

XSD XML Schema Definition

Notices

IBM and WebSphere are registered trademarks or trademarks ofInternational Business Machines Corporation in the United States and/orother countries. Java and all Java-based trademarks are trademarks ofSun Microsystems, Inc. in the United States, other countries, or both.Eclipse is a trademark of Eclipse Foundation, Inc.

Having thus described the invention of the present application in detailand by reference to embodiments thereof, it will be apparent thatmodifications and variations are possible without departing from thescope of the invention defined in the appended claims.

1. A method for operating a service registry and repository based on atriplestore database comprising: receiving a request to aggregate aservice document comprising elements; shredding the elements of theservice document to create logical objects within the triplestore;searching, for each logical object, for all policy attachments that havean association with the logical object; retrieving, for each locatedpolicy attachment, details of the policy and building a list of policiesand associated logical objects in the triplestore; and returning anindication of the list of polices and associated logical objects.
 2. Themethod according to claim 1, further comprising using the list ofpolicies and associated logical objects to compile a service documentcontaining details of all the policies that have relationships with theselected service document logical objects.
 3. The method according toclaim 2, where the compiled service document is aggregated with theselected service document.
 4. The method according to claim 1, whereobjects in the service document that have associated polices arerendered with a hypertext policy icon next to the object.
 5. The methodaccording to claim 4, where selection of the hypertext policy icon opensa new browser window, tab window or pop up window with the policydetails.
 6. The method according to claim 1, wherein shredding theelements of the service document to create logical objects, comprises:deriving a set of objects that represent the contents of the servicedocument; and linking the derived objects together in the triplestoresuch that the structure of the service document can be retrieved as anobject graph.
 7. The method according to claim 1, wherein searching forall policy attachments that have an association with the logical object,comprises searching over a whole repository, wherein the repositoryindicates another repository to be searched.
 8. The method according toclaim 1, wherein receiving a request to aggregate a service documentcomprises: using a universal resource identifier to identify theselected document in the repository inside an internet messagerequesting the policy aggregator to aggregate policies for the selectedservice document.
 9. The method according to claim 1, wherein building alist of policies and associated logical objects in the triplestorecomprises: including all the policy details in the document in adiscrete way so that a user can examine what policies are related to thedocument.
 10. The method according to claim 1, wherein building a listof policies and associated logical objects in the triplestore comprises:including only references to the policies in the document.
 11. Acomputer program product to operate a service registry and repositorybased on a triplestore database comprising: a computer readable storagemedium having computer readable program code embodied therewith, thecomputer readable program code comprising: computer readable programcode configured to receive a request to aggregate a service documentcomprising elements; computer readable program code configured to shredthe elements of the service document to create logical objects withinthe triplestore; computer readable program code configured to search,for each logical object, for all policy attachments that have anassociation with the logical object; computer readable program codeconfigured to retrieve, for each located policy attachment, details ofthe policy and building a list of policies and associated logicalobjects in the triplestore; and computer readable program codeconfigured to return an indication of the list of polices and associatedlogical objects.
 12. The computer program product according to claim 11,further comprising: computer readable program code configured to use thelist of policies and associated logical objects to compile a servicedocument containing details of all the policies that have relationshipswith the selected service document logical objects.
 13. The computerprogram product according to claim 12, further comprising: computerreadable program code configured to aggregate the compiled servicedocument with the selected service document.
 14. The computer programproduct according to claim 11, further comprising: computer readableprogram code configured to render objects in the service document thathave associated polices with a hypertext policy icon next to the object.15. The computer program product according to claim 14, furthercomprising: computer readable program code configured to open a newbrowser window, tab window or pop up window with the policy details inresponse to a selection of the hypertext policy icon.
 16. The computerprogram product according to claim 11, wherein the computer readableprogram code configured to shred the elements of the service document tocreate logical objects, comprises: computer readable program codeconfigured to derive a set of objects that represent the contents of theservice document; and computer readable program code configured to linkthe derived objects together in the triplestore such that the structureof the service document can be retrieved as an object graph.
 17. Thecomputer program product according to claim 1, wherein the computerreadable program code configured to search for all policy attachmentsthat have an association with the logical object, comprises computerreadable program code configured to search over a whole repository,wherein the repository indicates another repository to be searched. 18.The computer program product according to claim 11, wherein the computerreadable program code configured to receive a request to aggregate aservice document comprises: computer readable program code configured touse a universal resource identifier to identify the selected document inthe repository inside an internet message requesting the policyaggregator to aggregate policies for the selected service document. 19.The computer program product according to claim 11, wherein the computerreadable program code configured to build a list of policies andassociated logical objects in the triplestore comprises: computerreadable program code configured to build a list including all thepolicy details in the document in a discrete way so that a user canexamine what policies are related to the document.
 20. The computerprogram product according to claim 11, wherein the computer readableprogram code configured to build a list of policies and associatedlogical objects in the triplestore comprises: computer readable programcode configured to build a list including only references to thepolicies in the document.